To The invention relates generally to bar code scanners, and more specifically, to techniques for interfacing bar code scanners with computers.
For years, various bar code scanner manufacturers have been selling keyboard-wedge bar code scanners. With reference to FIG. 1, bar code scanner 108 is connected to a personal computer (PC) 100 keyboard controller port 104 and a computer keyboard 110 in an Y or wedge type configuration. Bar code scanner 108 may contain an on-board processor 109. PC 100 also contains a processor 101. The Y or wedge type configuration is implemented using interconnection cable 106. A first section of interconnection cable connects keyboard controller port 104 to bar code scanner 108, and a second section of interconnection cable connects bar code scanner 108 to computer keyboard 110.
From a conceptual standpoint, imagine that a digital switch 105 (within bar code scanner 108) is set up to selectively connect and disconnect the first section of interconnection cable 106 to the second section of interconnection cable 106. When the digital switch 105 is in a closed state, the keyboard controller port 104 is connected to bar code scanner 108 and computer keyboard 110 via the first and second sections of interconnection cable 106. When the digital switch 105 is in an open state, the keyboard controller port 104 is only connected to the bar code scanner 108, and the keyboard 110 is isolated from the bar code scanner 108 as well as the keyboard controller port 104.
When digital switch 105 is in the closed state, computer keyboard 110 and bar code scanner 108 are placed in parallel across controller port 104. This parallel configuration is used because keyboard controller 102 circuitry within presently-existing PCs (personal computers) 100 and laptop computers attempts to detect the existence of a computer keyboard 110 connected to the keyboard controller port 104. The controller port 104 needs to be connected to a computer keyboard 110, even if the keyboard is not to be used for subsequent data entry, and even if the controller port 104 is also connected to an input device other than a computer keyboard. If the keyboard controller 102 circuitry does not detect a keyboard connected to the controller port 104, the PC 100 and/or laptop may then disable the port, preventing any further inputting of data. In the operational environment of FIG. 1, this disablement poses a problem, because we desire to input further data as bar codes are detected and decoded.
In actuality, the use of a digital switch 105 to completely isolate the keyboard from the keyboard controller port is an over-simplification, presented for purposes of conceptual expediency. Real-world systems may isolate the keyboard using any of a variety of techniques. However, a common approach is to bring the keyboard clock line to a logic xe2x80x9clowxe2x80x9d state, while allowing the keyboard data line to float xe2x80x9chighxe2x80x9d. In practice, connections between the LED status indicator lamps (num-lock, caps-lock, and scroll-lock) and the keyboard controller port may remain in place, even while the keyboard is inhibited.
With the increasing use of laptop computers and keyless data entry, the keyboard controller port shows great potential as a convenient, somewhat standardized, and readily available data input channel. However, this potential could be advantageously exploited only if it were possible to find some way around the necessity of connecting this port to an actual computer keyboard. By way of clarification, there are a number of existing programs that do not require the use of a computer keyboard per se, but these programs have neglected to provide mechanisms by which a computer keyboard is emulated, so as to prevent the controller port from being disabled.
Assume that a conventional keyboard wedge bar code scanner is connected to a keyboard controller port of a PC or laptop, as shown in FIG. 1, while, at the same time, the keyboard that is connected in the parallel (Y) configuration is eliminated. Will the hardware configuration of FIG. 1 still function as desired? It is important to realize that keyboard-to-PC communications is implemented by means of a 2-way channel. Other types of data must be communicated between the PC and the keyboard in addition to information specifying the key or keys that were pressed. When a PC is powered up, the PC is programmed to check for the existence of a primary data input device, which is typically a keyboard. The PC begins a data exchange with the keyboard, and this communication is called xe2x80x9cpower-on diagnosticsxe2x80x9d. If the keyboard is not present, or if the power-on diagnostics fail, the PC will not boot up. Accordingly, if a normal boot-up is desired, the keyboard shown in FIG. 1 should not be eliminated. In the case of laptop computers, a similar situation exists. A communication protocol is used to sense the presence of an external keyboard that is connected to the laptop""s external keyboard port. If the laptop computer fails to detect a keyboard at the external keyboard port, then the laptop computer may disable its external keyboard port.
Even if a technique were to be developed by which a bar code scanner could successfully emulate a computer keyboard during boot-up, another problem would then arise. Eleven (11)-bit transmission protocols are utilized almost universally to provide keyboard to PC data transfer. The transmission protocol begins with a Start bit (low), followed by 8 data bits (these bits represent a scan code which, in turn, could be used to represent a portion of a detected bar code or a key press), a Parity bit (odd parity) and finally a Stop bit (high). Three of these 11-bit xe2x80x9cbytesxe2x80x9d are used to represent a xe2x80x9ccharacterxe2x80x9d. Problems arise because this protocol allows the PC (or laptop) to interrupt the transmitted sequence up through the 9th bit.
If the keyboard 110 or keyboard wedge scanner (i.e., bar code scanner 108) begins transmitting a data byte, the PC can prevent the successful communication of that byte, up to and including the 9th th transmitted bit. To make matters worse, a typical bar code includes a sequence of several 3-byte characters. An interruption at any time during transmission of that sequence will result in loss or corruption of the entire bar code. This keyboard inhibit problem is described in greater detail in a reference book entitled, xe2x80x9cPC KEYBOARD DESIGNxe2x80x9d, by J. Konzak, and published by Annabook.
With the advent of multitasking operating systems, sophisticated network operating systems, and dual-keyboard port laptops and PC""s, the problem worsens. Some of these operating systems interrupt keyboard port communications on a frequent and periodic basis, such as once every ten milliseconds. Of course, in operational environments where the keyboard controller port is not used with an auxiliary input devices, the computer keyboard will sense this stoppage of communications and retransmit the scan code after the PC releases its halt or inhibit of the keyboard. Existing bar code scanners are not so equipped. If a data transmission from a bar code scanner is interrupted, the scanner has no mechanism by which to ascertain whether or not a data entry error has occurred.
Existing scanners do not monitor for the existence of an inhibit signal, so the scanner cannot infer a data entry error based upon the existence of an inhibit. Pursuant to prior art techniques, bar code scanners had not monitored the inhibit signal because the decoded bar codes were wedged into the transmitted data for brief periods of time, relative to typed-in keyboard data. Also, as a practical matter, the keyboard BIOS virtually never inhibits the keyboard during scan code transmission. Any problems that may have been encountered were handled by changing certain programmable parameters such as inter-character delays or inter-scan-code delays.
In some existing wedge scanner systems, PC 100 maintains control over keyboard control port communications. After all, the PC is equipped to inhibit keyboard transmission at any time by sending out a xe2x80x9ckeyboard inhibitxe2x80x9d signal. However, a bar code scanner 108 could also be programmed to inhibit the keyboard, and some presently-existing bar code scanners are programmed take advantage of this fact.
Various keyboard wedge bar code scanners 108 have been programmed to transmit decoded bar code data on a character-by-character basis. This approach operates as follows: Test for active communications between the keyboard 110 and the PC 100. If no communication is detected, the bar code scanner 108 opens digital switch 105, thereby inhibiting the keyboard 110. The bar code scanner 108 then transmits a character, which, using standard protocols, includes three data bytes. If the bar code scanner 108 detects communications between the keyboard 110 and the PC 100, the bar code scanner 108 waits until such communications are completed before inhibiting the keyboard 110 and transmitting the character. After transmission of the character, the bar code scanner 108 releases the inhibit. Then, the aforementioned cycle begins again until all decoded characters have been transmitted by the bar code scanner 108.
This character-by-character inhibit was developed to allow for any additional communications that might be required between keyboard 110 and PC 100. Certain country-specific keyboards as, for example, those utilized throughout Germany, require that status information for one or more keyboard LED indicators be sent from the PC 100 to the keyboard 110, when the  less than shift greater than  key is pressed. These keyboard LED indicators are also present on conventional keyboards used throughout the United States, and are used to indicate the status of the Num-Lock (numeric lock), Caps-Lock (capital lock), and Scroll-Lock keys. Illumination of an LED indicates that the corresponding xe2x80x9clockxe2x80x9d function is active and operational for subsequent key presses, whereas non-illumination of an LED indicates that the corresponding function is inactive and not operational for subsequent key presses. The status of these LED indicators is tracked by the PC 100 and, therefore, the PC needs to communicate with the keyboard 110 so that the appropriate LED indicators will be illuminated or de-illuminated.
In operational environments where US-type keyboards are used, the character-by-character method allows for proper activation and deactivation of the LED indicators on the keyboard. For example, the caps-lock indicator will toggle properly. However, on many European keyboards, the caps-lock key functions differently than on U.S. keyboards. Pressing caps-lock a first time results in implementation of the caps-lock function on subsequent key presses. However, pressing caps-lock a second time implements a shifting function, instead of turning the caps-lock function off, as would be the case for a U.S. keyboard. The PC must accurately keep track of the number of times that the caps-lock key has been hit in order to provide proper drive signals to the keyboard LED indicators. However, if communications between the keyboard and the PC are subject to interruption, the PC may not be able to acquire accurate information about the correct operational status of the caps-lock, num-lock, and scroll-lock keys. Moreover, the PC may interpret received bar code characters as keyboard key presses, and attempt to update LED status information based upon one or more characters of a received bar code. If the character-by-character method is used in conjunction with a European keyboard, the PC may not acquire the necessary status information from the keyboard, or the PC may acquire superfluous information from scanned bar code symbols. The PC will send erroneous LED drive signals to the keyboard, causing inappropriate LEDs to be illuminated, and/or causing LEDs that should be illuminated to remain dark. Accordingly, every time that the bar code scanner sends a bar code to the keyboard controller port, it is then necessary to update the status of the LED indicators, or the indicators will not display accurate information.
Although the character-by-character method is useful in certain specific system applications, what would happen if keyboard 110 keys were being pressed at the same time that data was being scanned by the bar code scanner 108? Bar code data and typed-in data would be intermingled, thereby corrupting both sets of data.
The intermingling of bar code data and typed-in data in a keyboard-wedge configuration is prevented through the use of a message-based keyboard inhibit procedure implemented by the bar code scanner. In this manner, both the typed-in data and the bar code data will remain uncorrupted, even if the keyboard data is being entered substantially simultaneously with the scanning and/or decoding of bar code data. This message-based keyboard inhibit procedure tests for any communication in progress between the keyboard and PC. If no communication is in progress, the bar code scanner places a switching mechanism into a first state so as to disable communications between the keyboard and a keyboard controller port of a PC (personal computer), thereby inhibiting the keyboard. The bar code scanner then transmits the decoded bar code to the PC as a sequence of data bytes. The bar code scanner also implements all communications that are required between the PC and the keyboard during this time. The inhibit will not be released until all characters of the bar code have been transmitted by the scanner. Typically, three data bytes are used to represent each bar code character, and bar codes include a plurality of such characters. Once all characters of the bar code are transmitted, the bar code scanner releases the inhibit by placing the switching mechanism into a second state, so as to permit communications to take place between the keyboard and the PC. At this time, any keyboard key that was typed in during transmission of the bar code will now be transmitted from the keyboard to the PC. Presently-existing keyboards have built-in buffers, and, therefore, such typed-in data will not be lost.
Pursuant to a further embodiment of the invention, the first state of the switching mechanism inhibits the keyboard by placing a keyboard clock line into a logic xe2x80x9clowxe2x80x9d state, and allowing a keyboard data line to float to a logic xe2x80x9chighxe2x80x9d state. The second state of the switching mechanism permits communication between the keyboard and the PC by allowing logic xe2x80x9chighxe2x80x9d pulses on the keyboard clock line.
Message-based keyboard inhibit solves the problem of the keyboard and bar code scanner communicating on the same channel without interference. The invention can be provided by equipping the bar code scanner with software, firmware, and/or operating instructions. The user of the bar code scanner will be able to type-in data simultaneously with the scanner scanning and/or decoding bar code data. Both sets of data will remain intact throughout the typing and scanning interval.
Pursuant to a further embodiment of the invention, the bar code scanner is equipped with an automatic detection mechanism to keep track of the status of one or more keyboard LED indicators, including at least one of the Caps-lock, Num-lock, and Scroll-lock LED indicators. The automatic detection mechanism is optionally equipped to keep track of a scan code transmission protocol currently in use, such as make-Break, Make-Only, AT or PS2-type scan-code transmission protocols. The manner in which the aforementioned LED indicators react to key presses varies according to the country type of the keyboard.